…t it in the CodeUnit

…tores the MethodMap (line numbers for each method), and executable lines got a bug fix. UpdateSourceMap now saves mapped line numbers from .py to .cls

…PCJG (as well as code that unsuccessfully tries to save it into SQL)

…then wrote StorePyCoverage to store that data in a Coverage

Added ..CoveragePythons

Changed AddCoverageClass to add to ..CoveragePythons

Added ..PyCoverageTargets

Changed SetCoverageTargets (which is called when the user actually passes in coverage classes and routines, instead of it being in coverage.list) to fill in PyCoverageTargets with just the non .py part of the class name

Got UpdateCoverageTargetsForTestDirectory to update ..PyCoverageTargets in the case where there’s a coverage.list

Handle StartCoverageTracking

seems redundant to include the python in the new / relevant stuff: it’s new or relevant if its class is new / relevant

Added the python components of the old relevant classes into tPyRelevantTargets

With that being said, I think we need Snapshot to return the python targets for the relevant classes

In Snapshot: checked if the class has a python part (if it does, it’s relevant), and added those to the list of python new relevant targets. Took a snapshot of each of those

Combined tPyNewRelevantTargets into tPyRelevantTargets

…erageTracking to StoreIntRoutine to store the coverage results from the .py CodeUnits, resulting in python lines being marked as covered in .cls files

…e python now working end to end

…onitorResults

…re correct (per radon)

Turns out there's no .INT routine generated for .CLS files with only embedded python,
which means that we can no longer piggyback finding out which python files to track
by using the .CLS files. I now keep track of relevant and new python coverage targets separately

…ement)

…amplecovlist.list in the first directory now

…into EmbeddedPython

fetching changes from PR 41

…starts and finishes

Added in the listener interface from PR #42